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1.  Introduction 


1.1.  Overview 

Java™  is  perhaps  the  first  programming  system  that  is  both  widely  used,  and 
conceptually  clean  enough  to  undergo  a  formal  analysis.  This  represents  a  unique 
opportunity  for  formal  methods  to  make  an  impact  on  computing  practice.  Java  is  finding 
application  in  security  critical  applications  especially  Internet  programming  and  mobile 
code  applications. 

The  work  on  this  contract  focused  on  low-level  Java  Security.  The  Java  compiler 
translates  Java  class  definitions  into  platform- independent  target  language  known  as  the 
Java  Virtual  Machine.  The  Java  Virtual  Machine  (JVM)  is  a  type- safe,  stack- oriented 
abstract  machine.  JVM  code  (also  called  bytecode),  not  Java  source  is  transmitted  when 
an  “applet”  is  sent  over  the  Internet  and  remotely  executed.  Because  the  transmitted  code 
cannot  be  trusted  to  be  the  unmodified  output  of  a  correct  Java  (or  other  language) 
compiler,  the  code  must  be  checked  for  consistency  either  prior  to  execution  or  by  run¬ 
time  checking.  Thus  security  issues  in  Java  are  focused  on  the  JVM.  This  consistency, 
which  involves  type  safety  and  other  issues,  is  the  subject  of  our  investigation. 

A  secure  system  must  have  a  secure  foundation.  This  foundation  is  referred  to  as  low- 
level  security.  In  the  JVM,  language  mechanisms  are  used  to  insure  low-level  security. 
These  mechanisms  insure  that  mechanisms  for  attacking  a  system  such  as  buffer  overflow 
attacks  cannot  be  launched  against  the  JVM.  With  that  foundation,  high-level  security 
can  be  provided  by  a  security  manager  that  regulates  access  to  system  resources  and 
provides  a  level  of  separation  between  independently  executing  threads.  Kestrel’s 
research  program  will  continue  by  formalizing  the  JVM  security  manager. 

Kestrel  has  formalized  in  mathematical  notation  or  Specware  specifications  the  bytecode 
verifier  and  the  class  loader,  two  key  components  of  the  JVM  runtime  that  have  both 
subtle  semantics  and  play  an  essential  role  in  the  security  of  the  JVM.  Indeed  this 
investigation  has  exposed  bugs  in  the  Sun  implementation  of  the  JVM  that  leads  to  a 
failure  of  type  safety.  This  bug  exploits  the  interplay  of  the  bytecode  verifier,  the  class 
loader,  and  class  resolution. 

1.2.  Use  of  Specware 

Specware  is  a  prototype  system  developed  at  Kestrel  Institute  for  the  formal  development 
of  executable  code  from  specifications.  Kestrel  used  the  Specware  system  to  generate 
code  for  the  bytecode  verifier  from  a  formal  specification.  It  was  one  of  the  largest 
applications  of  Specware  to  date,  and  help  to  shape  development  of  the  system. 

1.3.  Accomplishments 

Note  that  funding  from  the  NSA  also  contributed  to  these  results. 

•  Kestrel  has  produced  the  first  and  to  this  date  only  full  formalization  of  the 
bytecode  verifier  that  includes  all  of  its  functionality. 

•  This  formalization  has  lead  to  design  improvements  that  we  are  proposing  to  Sun. 
These  improvements  will  allow  faster  and  more  flexible  loading  of  classes.  In 
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particular  the  bytecode  verifier  need  not  load  certain  specifications  to  insure  type 
safety. 

•  This  formalization  is  written  in  such  a  way  as  to  allow  extensions  of  the  verifier  to 
be  specified  in  a  modular  way.  Kestrel  anticipates  that  such  extension  will  be 
developed  to  add  new  security- related  functionality  to  the  JVM. 

•  Kestrel  has  written  Specware  specifications  for  a  subset  of  these  formalizations 
and  has  refined  these  specifications  to  executable  code. 

•  Kestrel  has  formalized  the  essential  nature  of  the  JVM  class  loader  and  is  able  to 
prove  a  type  safety  result  for  the  combination  of  the  bytecode  verifier  and  class 
loader. 


1.4.  Results 


This  effort  is  detailed  in  a  series  of  technical  papers  listed  in  appendix  A.  Most  of  the 
papers  describe  the  specification  of  the  JVM  in  Specware.  The  [4]  paper  lists  some  of  the 
problems  in  the  JDK  1.2.2  found  using  the  derived  bytecode  verifier.  A  simple  example 
showing  the  benefits  of  using  a  formally  derived  bytecode  verifier  developed  using 
Specware  as  opposed  to  a  handwritten  bytecode  verifier  is  illustrated  below. 

In  this  example,  there  are  two  classes:  A  and  B.  Figure  1  shows  that  Class  A  has  two 
simple  functions(change  and  m)  defined  for  integers.  Class  B,  shown  in  Figure  2,  just 
simply  extends  Class  A  to  include  versions  of  those  functions  for  float. 


Class 

\ 

{ 

int  i; 

A( ){  } 

void  change(int  j){ 

i  =  j;} 

int  m(int  j){ 

return  i  +  j;  } 

} 

Figure  1  -  A.java 
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Class  B  extends  A 

{ 

float  f ; 

B( ){} 

void  change(float  fl){ 
f  =fl;} 

float  m(float  fl){ 

return  f  +  fl;  } 

} 

Figure  2  -  B.java  (WRONG) 


Class  B  extends  A 

{ 

float  f  =  0; 

B( ){  } 

void  change(float  fl){ 
f  =  fl; } 

float  m(float  fl){ 

return  f  +  fl;  } 

} 


Figure  3  -  B.java  (CORRECTED) 


These  two  files  both  compile  ok  in  JDK  1.2.2.  However  if  one  was  to  disassemble 
B. class,  the  statement  return  f  +  fl  would  be  using  an  integer  add  instead  of  a  floating 
point  add  and  thus  could  result  in  an  obscure  error.  The  Specware  bytecode  verifier 
would  compile  B.java  and  give  an  error.  Figure  3  illustrates  a  change  that  would  make 
both  the  JDK1.2.2  and  Specware  bytecode  verifier  versions  so  that  the  B.java  file 
compiles  correctly. 
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1.  A  Specification  of  Java  Loading  and  Bytecode  Verification  Allen  Goldberg. 
Proceedings,  5th  ACM  Conference  on  Computer  and  Communications  Security,  San 
Francisco,  October  1998.  Kestrel  Institute  Technical  Report  KES.U.97.1,  December 
1997. 

2.  A  Formal  Specification  of  Java  Class  Loading.  Z.  Qian,  A.  Goldberg,  and  A.  Coglio. 
Proc.  15th  ACM  Conference  on  Object-Oriented  Programming,  Systems,  Languages,  and 
Applications  (OOPSLA'OO).  ACM  SIGPLAN  Notices,  v.  35(10),  October  2000,  pp.  325- 
336.  Also  Kestrel  Institute  Technical  Report  KES.U.99.6,  October  1999. 

3.  Type  Safety  in  the  JVM:  Some  Problems  in  JDK  1.2.2  and  Proposed  Solutions. 

Alessandro  Coglio  and  Allen  Goldberg.  Proc.  2nd  ECOOP  Workshop  on  Formal 
Techniques  for  Java  Programs.  June  2000.  Kestrel  Institute  Technical  Report 
KES.U.00.3,  June  2000. 

4.  Towards  a  Pro vably- Correct  Implementation  of  the  JVM  Bytecode  Verifier. 
Alessandro  Coglio,  Allen  Goldberg,  and  Zhenyu  Qian.  Proceedings  of  the  OOPSLA  '98 
Workshop  on  the  Formal  Underpinnings  of  Java,  Vancouver,  B.C.,  October  1998. 

Kestrel  Institute  Technical  Report  KES.U.98.5,  August  1998. 

5.  A  Formal  Specification  of  a  Large  Subset  of  Java(tm)  Virtual  Machine  Instructions  for 

Objects,  Methods  and  Subroutines.  Zhenyu  Qian.  Formal  Syntax  and  Semantics  of 
Java(TM).  Alves-Foss,  J.  (Ed.),  Springer  Verlag  LNCS,  1998.  Kestrel  Institute  Technical 
Report  KES.U.98.4,  August  1998. 

6.  Standard  Fixpoint  Iteration  for  Java  Byetcode  Verification  Zhenyu  Qian.  ACM 
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